IBIS Macromodel Task Group

Meeting date: 20 April 2021

Members (asterisk for those attending):
Achronix Semiconductor        Hansel Dsilva
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:       Ambrish Varma
                              Ken Willis
                              Jared James
Google:                       Zhiping Yang
Intel:                        Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                            * Ming Yan
                            * Todd Bermensolo
                            * Rui Yang
Luminous Computing          * David Banas
Marvell                       Steve Parker
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
SiSoft (Mathworks):         * Walter Katz
                              Mike LaBonte
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:
  
- None.

-------------
Review of ARs:

- Hansel to submit his PAM4 Thresholds clarification BIRD to the Open Forum.
  - Done, submitted as BIRD212.
  
- Randy to note in his email announcing the new BIRD212 that ATM recommends it
  be approved for IBIS 7.1.
  - Done.

- Fangyi to send his "Combined Redriver Flow" presentation to the ATM list.
  - Done.
  
- Walter to investigate whether any model vendors are generating legacy Tx
  models that optimize based on their downstream channel.
  - Done.  Arpad noted that depending on which proposal we end up using this
    question might not be relevant.  Walter agreed.  He said he hadn't heard
    back from the model vendor he contacted, but he thought this issue would
    not be relevant to the new proposal he planned to review at this meeting.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the April 13th
meeting.  Randy moved to approve the minutes.  Arpad seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD210 and BIRD211:
Walter noted that he had sent an email to ATM about another compromise solution to
the Redriver flow, and he shared the "Tx_Impulse_Init" presentation it contained.
He jumped straight to the key slide:

- slide 4:  Three flows
This side illustrates 3 flows A, B, and C.

- A:  Walter said this is the minimal change to the IBIS 7.0 flow that corrects
      the existing Redriver flow problem.  The output of Rx1 Init is combined
      with the output of Tx2 Init, and the result is passed in to Rx2 Init.
      This should be considered the default Redriver flow now, and he thought we
      all agreed on this.

Walter said the other two flows are alternatives he's proposing to help in cases
where they're needed.
      
- B:  In this flow the output of Rx1 Init is combined with the downstream
      channel, and the result is passed in to Tx2 Init.  Walter said this flow
      is valuable for electrical channel Redriver models.  If the Tx2 wants to
      optimize for the eye at the Rx2, it would have all the upstream and 
      downstream information it needs.
      
- C:  In this flow the Tx2 Init receives its downstream channel's response and
      the output of Rx1 (cumulative upstream response) as separate columns in
      the impulse matrix.  Walter said this is essentially what Fangyi had
      proposed in BIRD210, and it is required for some optical channels.
      
- slide 5:  New Reserved Parameter Tx_Impulse_Input
This new parameter is Usage Info, and it tells the EDA tool what the Tx model
expects for an input to Init.  Original values on the slide were:
  - Downstream - legacy flow, the Init gets its downstream channel's response.
  - Upstream - Init gets its cumulative upstream response.
  - ~Adapt - (does not adapt) - all of the flows (A, B, C) yield the same
    answer if the Tx2 does not adapt.
  - Both - this is flow C, the Tx2 Init receives two separate columns with its
    cumulative upstream and downstream responses.
    
Arpad said that "Both" to him implied together, not separate.  Curtis asked what
setting would be used for flow B, since it included the Downstream and Upstream
together.  Walter said the names of the four allowed values could be improved.

David asked if "Legacy" would be a better name for the legacy (Downstream) case.
Radek said "Legacy" was not a well-defined value because "Legacy" is a relative
term.  The group discussed new names for the 4 values and arrived at:
  - "7.0" - (later updated to "IBIS7.0" at Arpad's suggestion) - legacy flow.
  - "Combined" - flow B - cumulative upstream and the downstream are combined.
  - "Separate" - flow C - Column 1 contains the response of the Tx2's downstream
    channel, and a new column at the end of the impulse matrix contains the
    cumulative upstream response.
  - "DoNotCare" - Arpad's suggestion for the "does not adapt" case.  The EDA
    tool can pass whatever it wants to the Tx2 Init as long as the EDA tool
    keeps track of how to combine everything in the end.
    
Arpad reviewed some of the scenarios that had been problematic for earlier
proposals.  He asked if the A, B, and C flows all worked with crosstalk.  Walter
said they did.  He said every Rx must have all of its aggressors' responses in
its impulse matrix.  For the Tx, he said the EDA tool could either put the
impulse responses to the victims in the impulse matrix, or it could put the unit
impulse response in the impulse matrix and use the filter response that was
returned to compute all the combinations itself.  Fangyi agreed, with the extra
caveat that for Rx models the EDA tool should scale the unit impulse response
with a small epsilon to ensure the fictitious crosstalk column did not affect an
Rx that optimized based on crosstalk.  Walter agreed, and he added that any
model that optimizes based on crosstalk should probably be aware of any unit
impulse response type crosstalk terms and ignore them when optimizing.

Arpad asked to confirm that this proposal would work for optical channels.
Fangyi agreed that flow C handled optical channels.

Fangyi asked if we really needed flow B, since flow C give the model everything
it needs.  Walter said flow B is there because it's something you can do without
requiring a brand new model.  If you had a Tx2 that wanted to optimize itself
based on everything that goes into the input at Rx2, then flow B would work.
David agreed that the step from B to C is considerable, since flow C requires a
new column and changes to AMI model boilerplate.  Radek said we would be talking
about a new Redriver model in any event, since it would have to use/support this
new Tx_Impulse_Input parameter.  Arpad said simply adding a new Info parameter
to the .ami file is simpler than rewriting the executable model.  Curtis said an
existing Tx2 model that "works" with the legacy flow might prefer to have the
combined upstream and downstream information available.  If this were true, the
model maker could simply add the new parameter with the value "Combined" to the
.ami file.  Walter said he had many model vendor customers who wanted to do
just that, and their models asked the EDA tools to pass in the combined
response.  Arpad and David agreed this was a good reason to keep flow B as an
option.

Walter said that for the optical channels you would typically have 4 electrical
signals (perhaps at 56Gbps each) coming into the optical part.  It would combine
them into one signal on the order of 2000Gbps, and send it ~ 1m (short run), or
~100m (medium), or ~35km (long haul).  In modeling such a device, you would put
the optical channel and all of its non-linearities in the Redriver model itself
(either in the Tx executable model, the Rx executable model, or both).  Fangyi
said you could also have a pre-driver to model, so you might model the system
with a cascaded chain of two Redriver models.

Arpad asked if we could make the default value of the parameter match flow B
instead.  Fangyi said we want to preserve flow A and keep it the default so we
don't change the default input to Tx2 and possibly break a legacy Tx2 model.
Bob agreed that the default, including the case in which the parameter is not
provided in the .ami file, should stay flow A.

Radek said we have to carefully go over these flows and make sure they work when
there is more than one Redriver in the chain.  Walter said the new parameter
only applies to the Txs, and he thought everything worked fine if Redrivers were
chained.

Walter to submit BIRD211.1 with this new proposal and the changes agreed upon
during the meeting.

- Curtis: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.

AR: Walter to modify the new Redriver proposal as discussed during the meeting
    and submit it as BIRD211.1.

-------------
Next meeting: 27 April 2021 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
